Near field communications (NFC) technology has been standardised via various specifications and technical standards such as ISO//IEC 14443 (for proximity cards), and ISO/IEC 15693 (for the longer range “vicinity cards”), and various technical specifications published by the NFC forum.
Near field communications (NFC) technology has developed from the stage where it was employed primarily to enable contactless near-proximity transactions to be performed between a smart card and a reader to the stage, today, where NFC capability is built into many devices, e.g. mobile phones. Moreover, whereas contactless cards often were dedicated for use in a single application (e.g. ticketing on a mode of transport operated by a single company), NFC-enabled devices such as mobile phones are generally designed to be capable of participating in NFC transactions in different applications.
An NFC-enabled mobile phone generally has the capacity to emulate a reader (NFC initiator), to emulate a contactless card (NFC target/responder) and/or to operate in a peer-to-peer manner. FIG. 1 is a highly-simplified diagram representing an NFC-enabled mobile phone and illustrates connections and protocols that may be used when the phone acts as a contactless reader (represented using arrows with long and short dashes), those that may be used when the device operates in a peer-to-peer mode (represented using dashed arrows), and those that may be used when the device operates as a contactless card (represented using solid-line arrows.
In the present document the expression “responder” will be used for a device that responds to commands received by NFC as part of a contactless transaction, irrespective of whether the device is emulating a contactless card or operating in P2P mode. In a similar way, the expression “initiator” will be used for a device that issues commands by NFC as part of a contactless transaction, irrespective of whether the device is emulating a contactless reader or operating in P2P mode.
NFC-enabled devices, for example mobile phones, are becoming widely used in real world contactless applications such as payments, ticketing, identification, access control, healthcare, retail, and so forth. However, bare compliance with NFC technical standards is not necessarily sufficient to ensure adequate security in contactless transactions.
It should be noted that the expression “transaction” is used in this document in a general sense to designate an exchange of data to achieve some purpose (i.e. it is not limited to exchanges that result in a sale or acquisition).
Often, in devices that have NFC capability security is provisioned within a secure element (SE). The SE is envisaged and designed to provide security to, and confer trust on, the devices as they participate in the underlying contactless applications. Typically the SE stores data such as sensitive information, credentials, privileges, and so on.
Traditionally an SE is a hardware element that is typically realized on dedicated and highly trustworthy, tamper resistant platforms such as a smart card micro-controller and is typically enabled with ecosystems such as Java Card, MIFARE, and card management systems such as Global Platform.
In NFC-enabled devices that incorporate an SE, it is the SE that communicates with the NFC controller during performance of a contactless transaction. The host operating system (OS) of the device may be able to communicate with the SE to obtain certain non-sensitive data about the transaction, for example for display to the user, but cannot communicate directly with the NFC controller.
The form factor of the SE can be different depending on the specific implementation: for example it may be an embedded SE (surface-mounted integrated circuit), a suitable SIM card (e.g. UICC SE, SWP-SIM), or an SE in the form of a secure memory card (e.g. SD card, MMC). The acronym SWP-SIM refers to a SIM which is connected to the NFC chip (or “contactless front-end”, CLF) by a single conductor according to the Single Wire Protocol codified by the European Telecommunications Standards Institute (ETSI) in technical specifications such as ETSI TS 102 613 V.11.0.0 (physical and data link layer) and ETSI TS 102 613 V.11.0.0 (host controller interface). Hybrid NFC-enabled mobile phones incorporate more than one type of SE within the same phone.
More recently, there have been proposals to implement software-based secure element emulation (soft-SE), also known as host card emulation (HCE), in NFC-enabled devices such as mobile phones. This type of soft-SE is realised within an application processor—e.g. a Mobile Application Processor (MAP)—and executes within the device's underlying untrusted operating system (rich OS) such as Android. Tokens that the NFC controller obtains from the host OS may not be trustworthy.
In the present document, unless the context requires otherwise the expression “SE” or “secure element” designates a physical (hardware) secure element and a secure element implemented in software (program code) is designated “soft-SE”.
A soft-SE can co-exist with other SE form-factors (e.g. embedded-SE, UICC-SE, etc.) and provides greater control for platform/ecosystem providers. In devices that are HCE-enabled the NFC controller (CLF) is configured so that it can interact with the SE or the host OS (HCE) depending on the application in which the contactless transaction is being performed.
Serious security issues have been reported in respect of mobile platforms utilizing HCE. Various software-based security measures have been proposed to improve security in HCE-enabled devices, to compensate for the lack of a SE. Thus, for example, to mitigate the effects of a security breach payment tokens of temporary validity may be provisioned securely in the phone (from the cloud). However, these approaches for assuring security may require the intervention of additional parties and processes (e.g. token provision services), making the overall operation more complex and involving onerous administration.
In the face of the current lack of consensus in the industry regarding how to implement SE for NFC, there is a need for new security mechanisms, especially for HCE, in order to protect applications and services.